1. 我原本以為資料湖只是「把檔案集中起來」

我一開始把資料湖理解成一個大型 Cloud Storage Bucket，只要把 CSV、JSON、Log 等資料集中存放，就算完成。
但當原始檔、清洗後檔案、分析用資料開始同時存在時，我才發現問題根本不是「存不存得下」，而是：

哪份資料可以相信？哪份可以修改？哪份可以直接拿來分析？

所以我開始用 raw / clean / curated 來區分資料狀態，概念上則對應 Google Cloud 官方所說的 Medallion Architecture：Bronze / Silver / Gold。這是一種邏輯架構，而不是某個特定產品。

2.原始資料不要直接改

實際整理資料時，我原本很直覺地想把處理完成的檔案直接從 raw 移到 clean。
後來才意識到這樣會失去原始版本。
所以改成：

raw 保留原貌，clean 另外產生新的版本。

這個做法的好處不是「資料夾比較漂亮」，而是讓整條處理流程具有 可重算性。
Google Cloud 對 Medallion Architecture 的描述也強調 Bronze 是原始 Landing Zone，保留原始資料後，即使後續邏輯改變，仍能重新處理。

3. Lifecycle 其實不是「搬資料」，而是在寫資料政策

一開始我把 Lifecycle Rule 理解成：
30 天後轉 Nearline，90 天後轉 Coldline。
但我發現它真正重要的地方不是「自動搬家」。
而是：

把資料保留政策轉換成系統可以自動執行的規則。

Cloud Storage 的 Object Lifecycle Management 可以根據物件年齡、Storage Class、Prefix 等條件，自動執行 SetStorageClass 或 Delete。而且如果多條規則同時符合，系統還有明確優先順序，例如 Delete 會優先於 Storage Class 轉換。
這讓我對 Lifecycle 的理解從：
自動省錢工具

變成：
資料保留政策的執行器。

4. 我原本以為規則設好就結束，後來才發現「規則本身也有生命週期」

Google Cloud 官方提醒，Lifecycle 是非同步執行的，而且修改 Lifecycle Configuration 後，舊規則最多還可能持續作用 24 小時。
這代表一件事：
設定改掉，不等於舊行為瞬間消失。

如果我今天把：
30 天後刪除

改成：
60 天後刪除

那麼在過渡期間，仍可能有物件按照舊規則被處理。
所以我開始覺得，治理規則不能只問：
「現在設定是什麼？」

還要問：
「這個設定什麼時候開始有效？」

5. 不一定非得自己寫每一條 Lifecycle Rule

查 Storage Classes 文件時，我注意到 Google Cloud 還提供 Autoclass。
Autoclass 可以讓 Cloud Storage 自動管理 Storage Class 的轉換，而不是每一條規則都由人手動設計。
這讓我開始思考：
到底什麼時候應該自己寫 Lifecycle Rule，什麼時候應該交給 Autoclass？

如果資料的使用週期非常明確，例如法規資料 365 天後必須刪除，那麼明確規則比較合理。
但如果資料存取模式難以預測，Autoclass 可能更適合。
所以我不會再把「自動治理」理解成只有一種做法。
真正的選擇其實是：

• 已知政策 → 自己寫 Rule
• 存取模式難預測 → 考慮 Autoclass

這就是從「功能操作」走到「治理策略」。

6. 資料治理真正的問題，開始從「放在哪」變成「誰知道它是什麼」

當資料量還很少時，我自己知道：
data_clean.csv 是什麼。

但如果公司有幾千張表、幾十個 Bucket、數百個資料來源，檔名根本不夠。
這時候 Google Cloud 的 Knowledge Catalog 就開始有意義。
Google Cloud 現在把 Knowledge Catalog 定位成 AI-powered data catalog，它不是只列出資料的位置，而是替資料建立 Business Context 與 Governance。它可以協助團隊：

• 發現資料
• 管理 Metadata
• 套用治理政策
• 建立 Business Glossary
• 提供資料品質與語意脈絡

這讓我開始理解：
真正成熟的資料平台，不只是「有資料」，而是「別人也知道這份資料是什麼」。

7. 最後我才理解，Data Lineage 其實是在回答「這個數字怎麼來的」

如果某一天 Dashboard 上的營收突然少了 20%，真正要找的不是：
「哪個檔案怪怪的？」

而是：
這個數字從哪張表來？經過哪些轉換？哪一段可能出問題？

Google Cloud 的 Data Lineage 就是在建立這張資料旅程圖。
它可以追蹤：

• 資料來源
• 中間轉換
• 下游報表
• 模型
• 受影響的資產

Google Cloud 官方特別把 Data Lineage 的價值放在四件事情上：

• Trust / Verification
• Troubleshooting
• Change Management
• Compliance

從怎麼把資料分層？
一路走到：
「怎麼讓資料可以被信任、被追蹤、被治理？」

參考資料

1. Google Cloud — What is Medallion Architecture?
2. Google Cloud — Object Lifecycle Management
3. Google Cloud — Storage classes
4. Google Cloud — Knowledge Catalog documentation
5. Google Cloud — About data lineage